-
Notifications
You must be signed in to change notification settings - Fork 844
[Merge by June 2025] Update to Windows 2022 runner image #2582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merge by June 2025] Update to Windows 2022 runner image #2582
Conversation
924a68d to
52bd87e
Compare
52bd87e to
711ddb1
Compare
|
Shall we also retarget the PyCOMTest server project file in this PR? Not that it would make any functional difference but just to be in line with the default Win SDK version in the runner. |
.github/workflows/main.yml
Outdated
| Set-Location "C:\Program Files (x86)\Microsoft Visual Studio\Installer\" | ||
| $VsInstallPath = vswhere.exe -latest -products * -requires Microsoft.Component.MSBuild -property installationPath | ||
| [string]$ComponentsToAdd = @( | ||
| "Microsoft.VisualStudio.Component.VC.14.29.16.11.ATL" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to get info about the CI's VS and MSVC versions and this is what I got using vswhere -latest
https://github.com/mhammond/pywin32/actions/runs/14687605417/job/41218346703?pr=2582#step:6:6
$VS_PATH = vswhere.exe -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath
echo "VS_PATH=$VS_PATH" >> $env:GITHUB_ENV
echo "MSVC_VERSION=$(((Get-Content "$VS_PATH\VC\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt") -split '\.')[0..1] -join '.')" >> $env:GITHUB_ENV
echo "VS_VERSION=$(((vswhere.exe -latest -property installationVersion) -split '\.')[0..1] -join '.')" >> $env:GITHUB_ENVResults in:
VS_PATH: C:\Program Files\Microsoft Visual Studio\2022\Enterprise
MSVC_VERSION: 14.43
VS_VERSION: 17.13
Which is completely different than the 14.29 and 16.11 needed here. That's why I hardcoded this component version number.
.github/workflows/main.yml
Outdated
| # should be run twice for some reason | ||
| Start-Process -FilePath vs_installer.exe -ArgumentList $ArgumentList -Wait -PassThru -WindowStyle Hidden | ||
| Start-Process -FilePath vs_installer.exe -ArgumentList $ArgumentList -Wait -PassThru -WindowStyle Hidden |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find an explanation in any of the linked issues as to why we need to run this twice. But I confirmed it's needed. It sure doesn't help with the extra time it takes.
Assuming you're talking about Lines 133 to 136 in ddc14b2
To be as compatible as possible with anyone wanting to run the tests locally. And ensure we don't create tests that only run in newer Windows. Or is there some other advantages to targeting a newer SDK? |
…com/Avasam/pywin32 into update-to-windows-2022-runner-image
|
I must confess that I'm a little confused by the mess that Microsoft has created around the Currently the PyCOMTest server dll project file is targeted for the platform toolset v142 and the Windows SDK 10.0.22000.0. My local installation of Visual Studio 2022 Community Edition is currently version 17.13.6 and provides by default the platform toolset v143. As mentioned here I have to retarget the project file to platform toolset v143 for a local build which is a little annoying. Reading the communication regarding the removal of multiple VC build tools I would be surprised if the PyCOMTest server dll will still build after May 13th, i.e. after the rollout of the announced changes. IIUC retargeting the project file for the platform toolset v143 would be required. This would also have the desirable side effect that for a local build with the recent version of Visual Studio, i.e. 2022, no retargeting would be required. Regarding the targeted Windows SDK, I don't think that it makes any difference for the PyCOMTest server dll, so we should aim for a current version that's available in Visual Studio 2022. |
I don't have to retarget anything locally, but here's my installations: And I do have a couple (v142 and v143) MSVC build tools installed though
That's may 2024. We're already past that. And PyCOMTest did fail building w/o the manual component install I added.
|
|
OK, I give up. All I can say is that the Visual Studio 2022 installer did offer me to install the v142 build tools but after installing them the build did still fail because of the missing ATL header file. The installer did only offer the C++ ATL for the latest v143 build tools but not for v142.. I didn't investigate where I could probably get the C++ ATL for the v142 build tools and just retargeted the solution for v143 locally. If you think that keeping the project file targeted for the old v142 build tools on the newer 2022 runner I don't want to waste your and my time anymore with this version mess. |
Tbh I'm not thinking much here. I'm just as lost as you are, if not more. 😓 I just don't want the CI to stop working come June 2025 because of the eventual random brownouts and removal of If retargeting can avoid the Btw this is all a predecessor to #2581 . I wouldn't even have noticed the |
…e-to-windows-2022-runner-image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree this kinda sucks, but I also see no better options - thanks!









See actions/runner-images#12045
Had to manually install a VisualStudio component because of actions/runner-images#9701 / actions/runner-images#9873
The new step unfortunately takes an extra ~8 minutes. So I had to increase the timeout as some jobs can now take up to 21 minutes. I wish we didn't have to. Feel free to whine at Microsoft 🙃
(Is there some caching we could do?)